Recently I received a bug report for psmisc that basically supplied a patch so psmisc works in a cygwin environment. Nothing terribly exciting in that and the changes are pretty uncontroversial. One of the changes is in that instead of using rawmemchr to find the end of the string, cygwin doesn t have that function and so it is replaced by strchr. I ve not seen the function rawmemchr before so I had a closer look. Initially I was a little worried, rawmemchr tries to find the given byte starting at a given pointer but unlike strchr it doesn t stop unless it finds the character. I think the only time this function is safe, or is no more evil than anything else, is when you are searching for the NUL character which is what fuser in psmisc does. Still, the string being checked is coming from getcwd which requires a string or buffer length so perhaps it would be better to use memchr which is a little slower but has a maximum length parameter. If you have code that uses this function, you may just want to check how it is being used because it seems like an old bad gets function that plagued a lot of programs.

All started in December last year. I saw a red and a green pixel on my monitor. Moving the window containing the wrong-colors pixels corrected them. The wrong-colored pixels reappear from time to time in increased quantity. Then a second symptom appeared: The screen went black and came back one second later. This was triggered by moving a window and scrolling. I wasn t sure what the reason was. Either it was a bug somewhere in the X stack or some hardware was dying. dmesg showed multiple problems with the radeon driver:

[283808.667454] radeon 0000:01:00.0: ffff88021f815c00 unpin not necessary
[283808.667820] radeon 0000:01:00.0: GPU softreset
[283808.667823] radeon 0000:01:00.0: R_008010_GRBM_STATUS=0xE57024A4
[283808.667825] radeon 0000:01:00.0: R_008014_GRBM_STATUS2=0 00330302
[283808.667826] radeon 0000:01:00.0: R_000E50_SRBM_STATUS=0x200000C0
[283808.667832] radeon 0000:01:00.0: R_008020_GRBM_SOFT_RESET=0x00007FEE
[283808.682844] radeon 0000:01:00.0: R_008020_GRBM_SOFT_RESET=0 00000001
[283808.698840] radeon 0000:01:00.0: R_008010_GRBM_STATUS=0 00003028
[283808.698843] radeon 0000:01:00.0: R_008014_GRBM_STATUS2=0 00000002
[283808.698845] radeon 0000:01:00.0: R_000E50_SRBM_STATUS=0x200000C0
[283808.699845] radeon 0000:01:00.0: GPU reset succeed
[283808.717570] [drm] Clocks initialized !
[283808.765829] [drm] ring test succeeded in 0 usecs
[283808.765838] [drm] ib test succeeded in 1 usecs
[283808.765840] [drm] Enabling audio support
[283812.521265] radeon 0000:01:00.0: GPU lockup CP stall for more than 1000msec
[283812.521269] [ cut here ]
[283812.521294] WARNING: at /build/buildd/linux-2.6.35/drivers/gpu/drm/radeon/radeon_fence.c:235 radeon_fence_wait+0 365/0x3d0 [radeon]()
[283812.521297] Hardware name:
[283812.521299] GPU lockup (waiting for 0x00AE670A last fence id 0x00AE6705)
[283812.521301] Modules linked in: btrfs zlib_deflate crc32c libcrc32c ufs qnx4 hfsplus hfs minix ntfs vfat msdos fat jfs xfs exportfs reiserfs nls_utf8 udf ip6table_filter ip6_tables binfmt_misc ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp kvm_intel kvm parport_pc ppdev snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_emul snd_emu10k1 snd_ac97_codec ac97_bus snd_pcm snd_page_alloc snd_util_mem snd_hwdep snd_seq_midi radeon snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device ttm snd pl2303 drm_kms_helper coretemp usbserial joydev psmouse soundcore drm serio_raw intel_agp i2c_algo_bit lp parport hid_cherry usbhid hid firewire_ohci firewire_core usb_storage crc_itu_t e1000e ahci libahci pata_marvell
[283812.521360] Pid: 2194, comm: compiz Tainted: G W 2.6.35-24-generic #42-Ubuntu
[283812.521362] Call Trace:
[283812.521370] [<ffffffff8106089f>] warn_slowpath_common+0x7f/0xc0
[283812.521374] [<ffffffff81060996>] warn_slowpath_fmt+0 46/0 50
[283812.521390] [<ffffffffa01bd775>] radeon_fence_wait+0 365/0x3d0 [radeon]
[283812.521394] [<ffffffff8107f730>] ? autoremove_wake_function+0 0/0 40
[283812.521410] [<ffffffffa01bdf71>] radeon_sync_obj_wait+0 11/0 20 [radeon]
[283812.521418] [<ffffffffa01751a3>] ttm_bo_wait+0 103/0x1c0 [ttm]
[283812.521435] [<ffffffffa01d4e1a>] radeon_gem_wait_idle_ioctl+0x9a/0 150 [radeon]
[283812.521447] [<ffffffffa010f433>] drm_ioctl+0 463/0 520 [drm]
[283812.521465] [<ffffffffa01d4d80>] ? radeon_gem_wait_idle_ioctl+0 0/0 150 [radeon]
[283812.521470] [<ffffffff81162f0d>] vfs_ioctl+0x3d/0xd0
[283812.521473] [<ffffffff811637e1>] do_vfs_ioctl+0 81/0 340
[283812.521477] [<ffffffff811535f1>] ? vfs_read+0 181/0x1a0
[283812.521480] [<ffffffff81163b21>] sys_ioctl+0 81/0xa0
[283812.521484] [<ffffffff8100a0f2>] system_call_fastpath+0 16/0x1b
[283812.521487] [ end trace 6d5e03bab743abfa ]
[283812.521493] [drm] Disabling audio support
[283812.525575] [drm:radeon_ib_schedule] *ERROR* radeon: couldn t schedule IB(10).
[283812.525579] [drm:radeon_cs_ioctl] *ERROR* Faild to schedule IB !
[283812.527021] [drm:radeon_ib_schedule] *ERROR* radeon: couldn t schedule IB(11).
[283812.527024] [drm:radeon_cs_ioctl] *ERROR* Faild to schedule IB !
[283812.527921] [drm:radeon_ib_schedule] *ERROR* radeon: couldn t schedule IB(12).
[283812.527923] [drm:radeon_cs_ioctl] *ERROR* Faild to schedule IB !

The time between going black reduces every time. The system wasn t usable any more in the end. After testing that the screen was going blank on other systems like a live CD of Ubuntu and a not noteworthy proprietary system, it was clear that some hardware component was dying. My first assumption was verified after replacing it: My graphic card, a Radeon HD 4670, died. This was three weeks ago and around 25 month after I bought the graphics card. So I didn t have to worry if replacing the fan voided the guarantee, because the guarantee lasts only 24 month. Conclusion:

1. Not every error is a software bug.
2. The hardware component with the highest failure rate is the graphics card, followed by the motherboard. Four graphics cards died last year (in four different systems owned by four different people, in three different households).
3. Not every error is a software bug.

I've been very quiet on here for a few months, and the reason is (of course) because I've been doing other things. No surprise there, I guess! What I've been doing, first of all, is writing aCal, an Android CalDAV client with a lot of help from Chris Noldus. It's probably fair to say that Chris did most of the heavy lifting while I learned Java, did most of the UI & graphic design, and the low-level CalDAV synchronisation and geeky calendaring code. This is now available in the Android market for NZD$2.00 to help us fund further development and in a few days (or a couple of weeks) I'll get the source code up somewhere public (probably Gitorious) and it will be licensed GPLv3... When I get a moment - although refer to title :-) Of course on top of that I'd already committed to a second year of handling the sponsorship job for Linux.Conf.AU, so a fair amount of January was taken up with preparing for, and attending LCA in Brisbane where I took a lot of photos. LCA was, as always, a blast, and all credit to the fantastic team over in Brisbane who really came together when it seemed it was all going to fall apart after the flooding. This seems to be six long months of disasters around this part of the world, although until Tuesday I guess we thought we'd escaped the worst of it in New Zealand. After LCA I snuck home for a few days before flying off in the other direction, to UC Berkeley, for CalConnect XX where I managed to get in some great testing of the new Android CalDAV client, some excellent standards discussions, more photos and (even) a few days sightseeing. I've been home for a week from that now - just barely long enough to hug the kids, really - and today I am in the air once more, off to CeBIT in Hannover where I have been lucky to be sponsored a free booth in the Open Source Lounge by Linux New Media AG. My original travel sponsor slipped through the cracks, but I was fortunate that InternetNZ agreed to help fund me instead. If you're coming to CeBIT please do stop by the Morphoss table in the Open Source Lounge (Hall 2, F40) for a chat about DAViCal and Android - and anything else you want to talk about! I'll be there all week :-) And if I have some quiet time in that week (yeah, right!) I'll be trying to push out a new DAViCal release, which is overdue really, since the last one was two months ago.

DAViCal 0.9.9.4 is now available, along with AWL 0.46. This is a recommended upgrade with a focus on stability and reliability. Release notes are on the wiki at http://wiki.davical.org/w/Release_Notes/0.9.9.4. Most of the changes are subtle: fixes to small bugs or adjustments to correctness in respect to standards. In particular there were some errors in handling of various requests for addressbook data, and the support for WebDAV synchronisation is updated to draft -04 of the specification. One notable addition is the new '/feed.php/username/calendar/' URL which will provide an Atom feed of the events added to a calendar. This is pretty experimental at present, but any problems with it won't affect the rest of DAViCal so I felt it safe to include in a stable release series. I've also created a DAViCal Announce mailing list which in the future will be the primary place that notifications like this are sent to, so those of you who are subscribed here but really only want to see announcements should subscribe to that list. In a few weeks time (well, when I remember, I guess :-) I want to move the DAViCal General mailing list to a lists.davical.org mailing list. As of today I've moved the DAViCal developers mailing list there already (pretty easy since it did not involve moving servers) but the old address for that one will continue to work indefinitely. Also, as of yesterday, the sourceforge.net project name for DAViCal finally got changed, so DAViCal is now at http://sourceforge.net/projects/davical - yay! At the end of January I will be presenting about Calendaring and Free Software at Linux.Conf.AU 2011 in Brisbane - I hope you've all got your tickets already, because there isn't much time left now :-)

During my recent trip to Massachusetts for CalConnect XIX I passed back via New York, surfing a few nights on the couch at the Washington Cube Garden¹. This was just enough time for my new Davis VantagePro2 to arrive by UPS ground (phew!) causing me much consternation, as the box was about twice as wide as I expected it to be. On opening it I discovered that the reason for the size was the physical dimensions of the rain gauge, leading me to realise that I had actually bought exactly what I wanted: a high quality weather station. Also leading me to wonder how the hell I was going to get it halfway around the world with me the next day. Unfortunately that extra wide carrying case was in no way going to fit inside my suitcase. Fortunately it came with a handle. And those wonderful people at Air New Zealand gave me a Koru Gold upgrade for a 50th birthday present, so it was time to put it to the test... Travelling on the subway out to JFK was it's own little adventure, but I made it out to terminal 5 and wandered around a bit before concluding I needed to be in terminal 7. Once I was in the right place I found the fancy people's check in counter and the nice lady there was only too happy for me to carry it to New Zealand, though she did aver that perhaps the security scanners would be dubious. Not a hitch there though: I guess they're used to letting everything through that's not specifically denied, so weather stations are fine because nobody would be silly enough to even think of doing that... Being Koru Gold really helped at this point though, because it enabled me to queue jump use the priority boarding line when getting onto the plane, and every airline in the US seems to have gone all-out for this "checked baggage costs more" approach, so the planes all fly with empty baggage holds and totally overstuffed overhead lockers. If this progresses I shouldn't wonder that the planes will get so top-heavy they roll over, but through the miracles of priority boarding I was able to commandeer all the locker space I needed before anyone else had even made it past row 40. I confess that I was a little worried that it wouldn't be quite such plain sailing getting through LAX. I mean we all know what reputation this delightful little exit port has. In the event it was totally anitclimactic. If it has a handle on it, and it's about the same size and shape as a largish carryon then it's fine. There have been no recorded stabbings with wind vanes anyway - at least on aeroplanes - so clearly they are perfectly safe. Finally back in my country of birth, thinking I was home free, I breathed a sigh of relief transferred my bags and nipped off to the Koru lounge for a much needed shower and change of clothes after I snuck the station through another scanner. By now the handle had broken, so it was looking decidedly more 'box' like and less 'carryon' like, and when I eventually rolled up at the gate with my boarding pass the attendant made a valiant attempt to relieve me of it, but she was too slow and I danced around her and swanned up the gangway to take my seat. I was slow, this time, having missed the first boarding call, and all overhead lockers were crammed full. There was no seat in front of me to put the weather station under. Fortunately a nearby cupboard proved fit for purpose and it was secreted there and we were underway. At this point the guy two seats over said "didn't I see that weather station in New York?". Of course being bright yellow does make it a little conspicuous I guess, and I'm not renowned for my own inconspicuousness myself. So that's how I got my new weather station home, and you can see right away that doing things the easy way would never even occur to me. Possibly this is why I run Linux: there just isn't enough challenge when you run a different operating system. On Windows someone has always written a program for your new weather station, and a Mac user wouldn't be seen dead with it because it's black and beige and comes in a bright yellow box! So now I had to find some code to write. I looked around and very rapidly discovered that some software called vproweather was available, which would happily talk to my weather station and download the data from it, write web pages, stuff it into a MySQL database and so forth. All, obviously, far too easy, so I thought aha! I could convert that to PostgreSQL, and then I would be happy and relax with the thought of a job well done. So I downloaded the code in question an impressive several hundred kb of C code, cranked open a text editor and started to crawl through it and see where I could add the magic pixie dust to make it work with PostgreSQL. But it was not to be. My eyes glazed over or scales fell from them or something, and I realised that this particular edifice was beyond my help. Back to square one. I downloaded the Vantage Serial Protocol docs from the Davis Instruments website did some quick googling and decided I should write a module to talk this protocol. And I should write it in Perl (it was a Thursday, and Perl always seems more sensible on a Thursday, and not because of Douglas Adams, either). I beavered away into the night. Rain threatened, so I raced outside and installed the new weather station on the roof in the hopes that it's magnificent rain collector would collect. I raced back inside and was able to count the first (and so far, only) tip of the bucket. And so I now release upon the world Davis::VantagePro my first perl module. Well, the first one I care to share with the world, anyway. I have stressed it with very little testing, lumbered it with no planning or design whatsoever and so I feel it only fair that I should cast it upon the world with very little thought for it's survival or existential goals.

¹ I seem to recall one night we came up with some fantastic names for Micah & Biella's Washington Square apartment, but I couldn't remember any of the good ones and had to slap a new one on there. I should also mention my stay at the Acetarium in Boston, which was a fabulous few days, but it would pad this blog post needlessly, and I've already done that.

While preparing for the upcoming mini-debconf Paris, I noticed that we don t have any good presentation template for OpenOffice.org Impress. I spent a few hours browsing Debian presentations put online by many speakers and was unable to find one that would suit me. This situation was clearly unacceptable and I decided to spend a few hours to fix this. I selected a very nice wallpaper created by Alexis Younes, used The Gimp to add a translucent white box so that the text can still be read, and combined all this in a OpenOffice.org Impress template. Click here to download the template. You can also get the Gimp XCF file for the background image. By the way, the same wallpaper has been used by Sam Hocevar to create nice-looking Debian business cards. PS: I contacted Alexis Younes by mail and he agreed to put the wallpapers under GPL-2+. It has been clarified on his webpage.

Follow me on Identi.ca, Twitter and Facebook.

6 comments Support my work

I use ratpoison as window manager on my ASUS EeePC netbook nemo for more than two years now. But although I m very happy with ratpoison in the EeePC, there are two feature wishes which have been refused by upstream: One is more flexibel window name matching for the unmanage command. The other one is focus follows mouse between ratpoison frames. Well, I always guessed that it was possible, but it took until now to find outhow to implement focus follows mouse for ratpoison. There s an ancient but still useful tool called Not a Window Manager (nawm) which is a small awk-like interpreter offering mostly window handling functions. The following .nawmrc implements focus follows mouse in nawm:

window newwin;  # stores window to raise
window lastwin; # stores previous window to prevent race conditions
leave  
    lastwin = currentwindow;
 
enter  
    newwin = pointerwindow();
    if (name(newwin) != "" && newwin != lastwin)  
        raise newwin;
        sync;
     
 

The leave hook is necessary to prevent flapping between two windows if switched between them via ratpoison s commands. I also had to add the following hook to my .ratpoisonrc to work around some cases where ratpoison s own window switching didn t work anymore. Only happened with more than one frame with one frame banishing the mouse cursor was annoying, so I filtered that case:

addhook switchwin exec if [  ratpoison -c fdump fgrep -o frame wc -l  -gt 1 ]; then ratpoison -c banish; fi

Unfortunately nawm has been removed from Debian Sid about a year ago due to being buggy and orphaned. There was not upstream development for seven years or so either. So for the moment you can get nawm either from Debian Lenny or from snapshot.debian.org. But I had to fix a segfault in nawm when calling name() on a window without name to be able to use it at all, so you will probably have to rebuild it anyway with the following patch:

diff -u nawm-0.0.20030130/builtins.c nawm-0.0.20030130-patched/builtins.c
--- nawm-0.0.20030130/builtins.c        2010-10-25 06:00:02.000000000 +0200
+++ nawm-0.0.20030130-patched/builtins.c        2010-10-25 04:15:25.000000000 +0200
@@ -546,8 +546,12 @@
     *name = gcstrdup("");
   else
      
-      *name = gcstrdup((char *)nm);
-      XFree(nm);
+      if ((char *)nm)  
+        *name = gcstrdup((char *)nm);
+        XFree(nm);
+        else  
+        *name = gcstrdup("");
+       
      
  

And yes, I m thinking about adopting and reintroducing the nawm package into Debian Sid. But I d prefer if anyone could give me a hint how to do this with more current and still maintained tools (or a patch against ratpoison :-). I looked into suckless-tools, but I haven t found anything in there which provides hooks on X events. And the Perl module Tk seems to be able to set X event hooks, but only within the application being written itself.

Finally, six months after releasing 0.9.9, and about three months after when I would have preferred to have released it, I've released version 0.9.9.2 of DAViCal. In fact most of the changes were included in 0.9.9.1 which was more quietly released last week to a select audience of keen testers. They found a few bugs, and these are resolved and so 0.9.9.2 is the release I hope people will be able to find useful for some time into the future. In a couple of weeks, once it's been in Debian Sid for a respectable time, I hope to ask for a freeze exception so that we can include this version into Debian Squeeze when it is released. Given that I missed the cut by a hair or two for Lenny so there is no DAViCal currently in a Debian release I think I can be hopeful on this count. Certainly this fixes a few issues with 0.9.9 which will cause annoyance if they haunt me for the next few years :-) As well as the rafts of bug fixes and such, the exciting new feature added in 0.9.9.2 is the first support for CardDAV. At this point you need to create the addressbook collection yourself, and there is no import facility, but at least you might be able to use DAViCal to store your contacts. Enjoy!

I'm a keen amateur photographer and have been since I was at school. Of course back then it involved smelly chemicals, strange lights and dark rooms. The expense and hassle of film eventually did it in for me and in 2000 I bought my first digital camera. After a series of increasingly sophisticated devices, back in 2007 I bought a Nikon D80 and soon thereafter I discovered that you can do things with raw camera files that have some analogies to the darkroom processing of my youth. For most of the time since then I've used UFraw for processing my raw images, combined with increasingly sophisticated batch files to harass it into shape. It has increasingly frustrated me that UFraw doesn't do several things that are essential to processing most files, since once the image leaves that programming it usually ends up in an 8-bpp processing path. It seems to me that the saving the processed image into an 8bpp format like jpeg is the last step before leaving the image alone. Of course this can't always be the case since sometimes a judicious use of the 'Resynthesizer' plugin can make some unsightly elements just disappear, or one needs to carefully apply some censorship to the 14 year old in the background so that the 7 year-old's parents can put the photo on the mantelpiece without worrying about what Granny will say about how much better children's manners were in her day. I'm hoping too, that when I have grandchildren I'll be able to tell them that 'in my day we only had 8 bits per pixel, and we were lucky', but The Gimp isn't there yet, no matter how much promise Gegl seems to offer. The thing that has particularly annoyed me is sharpening. UFraw doesn't, and as a result my workflow has either involved applying some blanket sharpening, much like the camera does, or moving the image into a second tool just to apply some sharpening. This week has been particularly demanding, as the school asked me to 'take some photographs of the production'. So of course that's a thousand-odd photos that I want to do a cull down to a hundred or so, and then I want to quickly do justice to the good ones so I can move on to other stuff. Well this time my frustration with UFraw hit that ceiling that got me to try something else. I've done this in the past, and found myself going full circle and ending up right back at UFraw with a few extra lines added to my script, but this time I tried rawstudio and in processing the 'can you do the class shots overnight please' test it produced much nicer results in much less time than I have ever been able to with UFraw. So I've switched, and the more I use it the more convinced I am that UFraw will be getting uninstalled pretty soon. That's not to say that rawstudio is perfect: it isn't. In particular it has some user interface failures that are kind of annoying to me, but they aren't enough to stop me using it. In fact I liked it so much that I immediately had to pull the nightly repository and build that, just to get the new saturation handling. The user-interface niggles that do get to me are:

• The keyboard key to switch between zoom 1:1 and zoom to fit is '*', which I have to access with 'shift' down since I'm on a laptop. This was less bad when I discovered I could right-click, but it's still annoying. 'z' would be a much better choice for right-handers, or '/' for left-handers. Or perhaps they could both be made to work. When working on an image I often want to switch between some particular area and the whole image when checking colour balance, sharpening, noise, etc, so this is one of the most used keyboard functions.
• Using the mouse wheel to adjust sliders varies greatly in it's effect. A single detent for contrast or saturation often overshoots the useful range, so I have to drag the fiddly slider a fiddly pixel-and-a-half to go from a contrast of 1.00 to 1.03.
• Not all modifications to an image show in the UI. When I crop or align an image RawStudio remembers the settings for these things (which is fantastic) but if I come back three months later I might not realise I'm looking at a cropped image. I can see all of the hue, saturation, sharpening and so forth, but there should be something in the UI to indicate that the crop and alignment have happened also.
• It confuses me what settings get applied to a fresh image. I seem to get some kind of random selection of which DCP profile is being applied, and there's no way to set a default sharpening or noise reduction. Of course some of this is hard: noise reduction defaults really need to change depending on camera & ISO, and sharpening defaults probably should vary by lense and aperture too, to some extent.
• The icon view runs across the top, taking up important screen real-estate. On my widescreen laptop I'd like the option to run it vertically where otherwise there's wasted space.

Things that I immediately love, over what UFraw gave me:

• Sharpening.
• Straightening images.
• Cropping images (in some versions of UFraw this works, and in some it's broken, but the UI is useless in all of versions I've seen).
• Colour profiles.
• Lens corrections.

Things that I immediately miss from UFraw:

• White balance presets.
• Wavelet noise reduction.

There are a bunch of things that RawStudio also does that I haven't particularly found a use for yet, but which I suspect I will quite like when I do. The image classification and stuff seems likely to be useful, for sure. In choosing to switch RawStudio I also looked at RawTherapee, which has recently relicensed under the GPL, but I chose RawStudio because it has vastly better performance on my laptop, and because I found the interface much more immediately accessible. RawTherapee also exceeds what UFraw can do in many ways, and looks like it might be useful for the really difficult cases, but learning to drive it with any facility could take some time. Especially if you only have an i7 740QM with 6G RAM, it would seem.

A few days ago I talked about how noisy my new Dell Studio 15 was but I can now report back with the beginnings of a solution to that problem, and it doesn't appear to be ACPI related. The first clue I needed was that if I switch to the proprietary fglrx drivers for the Radeon the fan quite quickly drops off to a much more reasonable level. It seems the fglrx drivers have issues, however, in particular I get big black patches on my screen. This video corruption happens especially in Firefox, but sometimes in other applications as well. They also appear to screw up my suspend/resume, which is probably even more annoying to me. The second clue that I needed was that Radeon power management support has only just made it into recent kernels. Thanks to Michael Kirkland for providing me with both of those clues :-) Looking under /sys/class/drm/ I find a whole bunch of stuff, but in particular there are /sys/class/drm/card0/device/power_method and /sys/class/drm/card0/device/power_profile. Looking through the kernel source code I can see that power_profile can be set to low, mid, high, auto and default, while power_method can be set to either dynpm or profile. Trying out all of these values, it seems I get the quietest result with the profile method and either the low or mid profile. The dynpm method is nearly as good, and I would think it should really be the default for a 'Mobility' chipset. From the detailed benchmarking that Phoronix did I wonder if it shouldn't be the default for everyone. For myself, I see some small 'tearing' artifacts occasionally when running with the low profile. These disappear when I run with the mid profile, and since that seems to have pretty much the same temperature (and noise) results I'll go with that one. Though the laptop often does still make more noise than I would prefer it to, it is no longer annoying everyone in the room. Not unexpectedly this seems to have a huge impact on power use, too. It appears that the laptop should now give me around 4.5 hours when I do everything I can think of to lower the power use, whereas before it was more like 2.5 hours. Now I guess I can get back to hacking on DAViCal...

Really, I should have known better than to buy myself a rather 'bleeding-edge' laptop. I suppose I've been lucky with my last couple of laptops and was thinking that pretty much everything works on Linux. Or maybe I'm being picky, because in fact pretty much everything does work on my new Dell Studio. I bought this laptop mainly because it has a 1920x1080 screen, without being a 17" monster. I had such a monster about four laptops ago (an enormous Sony Vaio weighing in at around 5kg and with a 1hr battery life) and it was an disaster: lots of weird proprietary stuff that never worked, like the external speakers in the docking station. But I loved that screen right up until the day Fraser threw a pair of scissors into it. With the advent of mass-market 1920x1080 screens I've been waiting for them to arrive in laptops at a reasonable price, and the availability of this screen in a few possible laptops seemed to me to be that point. It's a Dell Studio 15, and as well as the nice screen, it comes with a new Intel i7 Quad Core CPU, 6G RAM, 640G hard drive and a Blu-ray drive. While there are a few similar models around this one seemed to have the best mix of features-for-weight-and-price, so I bought my first Dell. I built a USB key with the latest Debian Installer from Squeeze and installed that and everything came up pretty well. I had to use the broadcom-sta driver for the wireless, since the BCM 43224 is not (yet) supported by the free b43 driver (though from looking the mailing list people seem to be working on it, and it looks like it might not be too far away). Everything seemed good. X came up on the (georgeous) screen. I don't care too much about 3D performance, but it was nice to note that the ATI 5000 series is expected to have full support as soon as it's integrated into the right places - it seems the code is written, and public, it just isn't incorporated into the 'radeon' driver quite yet. The fact that ATI is nowadays a free-software friendly company was one of the reasons for choosing this, in preference to an NVidia-based laptop. But it seems that it isn't all roses. The fan in the laptop seems permanently on, and not on, in a quiet-just-barely-audible way, but ON, in an 'IN UR LAPTOPZ KOOLIN UR P0RCESSAZ' kind of a way. Too damn noisy for me to concentrate in a quiet room. I've investigated what's going on, and it seems likely there are some ACPI misunderstandings happening. Some googling and some pecking around in /sys makes me wonder if the laptop expects some kind of configuration choice between favouring Active cooling and Passive cooling, and it's defaulted to the first one. Perhaps you get better benchmarks that way. Linux ACPI also seems to only half understand it, it has two thermal zones, and one of them always appears with 0 temperature. I can see set points for the fans, but have no control over them. In particular this got me out reading the ACPI 4.0 specification, and it explicitly mentions this choice of favouring 'Active' vs 'Passive' as being done by configuring the passive trip point setting to a higher value than the low & high active trip points. In the ACPI 4 spec (page 409) it says:

To implement a preference towards performance or energy conservation,
OSPM can request that the platform change the priority of active cooling
(performance) versus passive cooling (energy conservation/silence) by evaluating
the _SCP (Set Cooling Policy) object for the thermal zone or a corresponding
OS-specific interface to individual devices within a thermal zone.

This laptop is showing 'passive' at 95000 millidegrees celsius, and 'active' at 55000 / 75000 so right in line with the suggestion. However I don't see any way in Linux to change these trip point values, and in any case I'm not convinced the laptop is actually obeying them at all. It should be that if I do nothing on the laptop for a while the temperature would surely drop below 55 degrees celsius. Surely a modern laptop will sit at under 40 degrees when it's quiescent, and the temperature sensor that does show me something sits at around 30 degrees in this too, 26.8, to be overprecise. That one doesn't budge either. Looking in /sys/ I can't for the life of me find a way to set that cooling policy, and when I disassemble the DSDT it looks like a noop... Thinking that perhaps there was a newer BIOS, I looked at the Dell site and found there was one. Great! Investigating even further, it seems Dell hardware has some interesting capability via libsmbios and some utilities which will let me install my BIOS from a Linux system... even better! Linux is a second-class citizen though, and when I look for the Dell BIOS Hdr file I need there is no version of the file for this laptop - let alone the current BIOS version. And when I download the BIOS from Dell's website and unzip the first layer of packaging I find that both of the files inside will only run on Windows. I added a FreeDOS boot stanza to Grub 2 in order to discover this, also discovering in the process that this is not well explained, and I could not find how to do it on the FreeDOS or Grub2 websites, so in passing, here is what I added into /etc/grub/40_custom :

menuentry 'BIOS Flash 1558 A09' --class os  
        set root='(hd0,msdos1)'
        linux16 /boot/memdisk
        initrd16  /boot/1558_A09.img
 

Which certainly does boot FreeDOS from Grub2, into the image built from the 8M FreeDOS base image, and which I called '1558_A09.img' because that seems to be one of Dell's reference numbers for this model / BIOS version. So still no BIOS update for Andrew, it seems, and the laptop is probably going to continue to be noisy for some time. Possibly forever. Suspend/Resume works though. Kernel mode-setting for the ATI Radeon Mobility HD 5450 (or whatever it is) seems to work. Building kernels seems to work. The Blu-ray drive seems to work, at least as far as reading CDs - just because I got a laptop with a "Full HD" screen doesn't mean I watch movies on it: those pixels are for programming on! In any case, after reading the literature of pain about playing Blu-ray disks on Linux I'm convinced that we won't be shelling out to buy one any any time soon. After a bit more frustration I did manage to get the BIOS installed, using the hack I found here of running the Windows BIOS update under Wine and copying the BIOS file out of the temp directory while the error message is displayed. I could then download a random DOS-installable Phoenix BIOS to get copy of phlash16.exe and put those two files on the FreeDOS image I created earlier. Finally I was able to put that learning about how to boot FreeDOS from Grub2 to good use! Unfortunately, having jumped through all of those hoops (including the frustration of trying to build and use Dell's firmware-extract tools on a Debian system), the fan continues to grind away at annoying volume, with no way that I have been able to find to control it, and the temperature sensors also seem wrong, since one doesn't budge from 0 and the other doesn't budge from 26800. During boot I get a bunch of error messages, like:

[    1.049936] \_SB_.PCI0:_OSC invalid UUID
[    1.052202] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
[    1.052210] pci 0000:00:1c.0: PME# disabled
[    1.065228] pci 0000:07:00.2: PME# supported from D0 D1 D2 D3hot D3cold
[    1.065237] pci 0000:07:00.2: PME# disabled
[    1.079086] Unable to assume PCIe control: Disabling ASPM
[    1.086412] HEST: Table is not found!
[    1.249906] ACPI: Fan [FAN0] (off)
[    1.249959] ACPI: Fan [FAN1] (off)
[    1.250093] [Firmware Bug]: ACPI: ACPI brightness control misses _BQC function
[    1.259118] acpi device:02: registered as cooling_device2
[    1.262132] thermal LNXTHERM:01: registered as thermal_zone0
[    1.262139] ACPI: Thermal Zone [TZ00] (27 C)
[    1.262561] thermal LNXTHERM:02: registered as thermal_zone1
[    1.262571] ACPI: Thermal Zone [TZ01] (0 C)
[    1.262598] ERST: Table is not found!
[    2.769664] i801_smbus 0000:00:1f.3: PCI INT C -> GSI 18 (level, low) -> IRQ 18
[    2.769670] ACPI: resource 0000:00:1f.3 [io  0x1840-0x185f] conflicts with ACPI
                         region SMBI [bus 1840-184f pref window disabled]
[    2.769672] ACPI: If an ACPI driver is available for this device, you should use it
                         instead of the native driver

I don't yet know what this all means, so I guess I'll be signing up for the linux-acpi mailing list to see if there's anything I can do to get things working better. Any pointers will be gratefully received :-) Right about now I wonder if maybe I should have gone for the HP or the Asus, even if they were a little heavier and a bit more expensive and next time I get a new laptop I must remember not to spend more than $900 (USD$600) on it. [Updated: 2010-09-08... Noise Problems Solved

I do like that some of my friends in Debian have conspired to set up the website http://thank.debian.net/, and I composed this little Haiku in their honour:

Debian is fun
for seventeen years.
Beautiful balloons.

I'd also like to thank everyone involved in Debian over the years for being such a lovable, friendly, enjoyable and welcoming bunch of people to work with. It's tempting to single out people for special mention, because there are people who do exceptional work in the project, but the list would go on for so long, and I would be afraid of missing out someone who would be obvious five minutes later, and then I'd have to come back and edit this post repeatedly with the names of more and more people over the coming days. We all know exactly what a chore that kind of maintenance is. So I'll just give up completely and thank everyone, and if you think you deserve a special thanks, you probably do, and I'm sure you're on that list in my head. When we meet, as I hope we shall, let me shake your hand, lend you my ear and buy you a $BEVERAGE of your choice. Thank you,
Andrew McMillan.

I've been working on implementing CardDAV support into DAViCal at the moment, and the first problem I encountered when I went to try and use it from iCal, was that the configuration on iCal didn't seem to want to let me enter a URL to my addressbook. After I hauled out Wireshark and watched what was happening on the server it was clear that it was doing an SRV request to try and find the CardDAV server for the domain I had entered in. Unfortunately the DNS management front-end that I normally use doesn't support SRV records, so I was all ready to switch my whole DNS infrastructure around (one of those 'round tuit' tasks that's been on my todo list for somewhat more than a year) until I wondered if the magic that is dnsmasq would be able to help me out. It turns out that it can, and so after a little searching I'd managed to track down the magic syntax to do this:

srv-host=_caldav._tcp.home.mcmillan.net.nz.,davical.home.mcmillan.net.nz.,8008
srv-host=_carddav._tcp.home.mcmillan.net.nz.,davical.home.mcmillan.net.nz.,8008

Of course this is a special-case server for testing at home, and I run it on the funny port because it makes for less pollution when I sniff the traffic coming in. In the real world you'd want to add SRV records for caldavs and carddavs, to get SSL for these services, something like:

srv-host=_caldavs._tcp.home.mcmillan.net.nz.,davical.home.mcmillan.net.nz.,443
srv-host=_carddavs._tcp.home.mcmillan.net.nz.,davical.home.mcmillan.net.nz.,443

Once I'd done that, and put in a few more hours of debugging, DAViCal was working with iCal's CardDAV, at least for viewing / editing / deleting contacts - there's still some work to do yet on searching. I've now also got it working with Evolution's 'WebDAV contacts' plugin as well, after a tip from Milan Crha on the Evolution IRC channel. Heather gets home soon with the Apple phone I gave her when I upgraded to Android, so I'll hopefully be able to test against their new OS release and then get a new DAViCal release out next week. Maybe. Hopefully :-)

I've now released DAViCal 0.9.9, after five pretty intensive weeks of work. This includes a number of features that were implemented to support dotCal, which has now replaced their old Cosmo backend with DAViCal to break through a performance bottleneck. That turned into a six-week challenge, because Cosmo had wandered some distance from where calendaring standards are currently going, and so there was a lot of work under the covers of dotCal to switch from using various Cosmo-specific features to do the same thing, using open calendaring standards like CalDAV. One standard that Cosmo did support, and which DAViCal now supports also, are WebDAV tickets. Unfortunately the draft RFC for webdav tickets expired, and was never very well thought through, but the functionality is useful, in order to be able to hand people a secret 'ticket' that they can use to grant specific privileges to a single calendar. There's no UI in the DAViCal admin pages for this yet, but expect one to arrive in 0.9.9.1. Something that dotCal lets people do in the web calendar, is to add subscriptions to other dotCal user's calendars, which is a very nice feature, and certainly one we didn't want to lose. In Cosmo this was done by simply duplicating the calendars on a regular basis - a very resource intensive approach! So in order to support this in DAViCal I decided to add support for the WebDAV 'BIND' method, allowing calendars to be linked from one place into another, without requiring all the events to be duplicated. Mixing that up with the WebDAV tickets, it turns out to be very easy to make that stuff work in a read/write manner, and so I did that as well. Again, unfortunately there is no UI to see this at 0.9.9, but something should be in place for 0.9.9.1 because I know that this combination will be particularly useful to people using principal-centric CalDAV clients like the iCal, and especially like the iPhone, which can't see delegations, and where this would be an especially useful feature. The other major feature added in 0.9.9 is the long-awaited work on the Scheduling Extensions for CalDAV. This is currently an expired draft, but I've checked with Bernard Desruisseaux and there will definitely be a new draft out very soon with a few minor changes, and then there will be a push to finalise it as an RFC. Most of the work on this was done by Rob Ostensen, who has been working on a few DAViCal features now, and it was great to meet up with him in person at LCA 2010. Rob has also added support for pulling groups from LDAP into DAViCal 0.9.9 too, which will please a few people. This is the 0.9.9 release for a reason, too: it implements pretty much all of the functionality that a CalDAV server can usefully do at this point. The work that Rob did to get the scheduling extensions done was really the only hole in coverage of what current clients can do, and in the 0.9.9 series I plan to polish up what we have, add some basic UI to expose the tickets and binds (since no clients really do that at all, other than dotCal, which is proprietary :-). I'll also be working on implementing the bones of CardDAV support, and Rob will be moving on to implementing some parts of the iSchedule draft for server-to-server calendar scheduling. Enjoy!

For several years now we've been buying our groceries online. It's worked well, and for the last couple of christmases I remember Heather adding a six-pack into the pre-christmas order so she could pull it out and hand it off to the delivery guy. Fair enough too, because he was their front-line man. He was the guy who had to actually meet the customer, and even if only for two minutes face time, the impression he gave with his cheery "seeya mate" on the way out, and his always-happy smile, was that getting the groceries delivered was fun. Well that ongoing encouragement has gone now. His surly replacement who moans about having to carry the boxes up a flight of stairs does nothing to promote a repeat experience, and he brings into sharp focus the disadvantages of online grocery ordering: sometimes the wrong thing is substituted, or sent. Or the fruit doesn't travel quite so well as it does with the personal loving kindness we supply in our own padded wagon. Two visits from the new guy, and we're back to driving to the supermarket ourselves, patrolling the aisles once more in a cereal haze of consumer demand. Distress-purchasing done, and back to the car A.S.A.P. Carrying our own boxes up the stairs. I hate it, which is why I promoted the idea that we try this online grocery thing a few years ago, and it's worked just fine until this sullen bastard came along and destroyed the fun. I wonder how the company feels? Do they realise what this person is doing to their customers? Will they notice, and if they do, will they even be able to tell where the source of the problem is? In these days of increasing online experience, customer service is still important, if not more important than ever before.

After a whole bunch of drastic changes, lots of bugfixes, rewriting and refactoring, I released DAViCal 0.9.8 on Christmas day last year. I didn't release it very publicly, because I knew it sucked significantly. In an increasingly fast turnaround I've subsequently released 0.9.8.1 to a somewhat wider audience while I was at the recent Calendaring and Scheduling Consortium meeting in Costa Mesa at the beginning of the month. Earlier this week I released 0.9.8.2 to the more interested of the DAViCal userbase. So finally, yesterday, I released DAViCal 0.9.8.3 to fix the few significant problems that were left with that, and this is the release that I'm telling everyone about, because I believe it should be a good stable platform to people who want to upgrade their production DAViCal servers, or who have been hanging back from using DAViCal until the platform was a little more stable.
<!--break-->
This release marks some significant departures from previous DAViCal. I've decided to walk away from some of the more ancient legacy software I tried to work with in the past (PHP4 & PostgreSQL 7.x), to move to support the most ancient-but-not-superseded legacy Linux release I know of, which is CentOS / RHEL, so DAViCal now has a minimum requirement of PHP 5.1 & PostgreSQL 8.1. The biggest changes to DAViCal are under the covers. It is server software, after all, so the largest changes often are not visible on the surface. What has changed is that the architecture for constructing responses as been refactored into a core object which is used to access any DAV resource in the system. This greatly simplifies the general coding and reduces a fair bit of code duplication which had been happening. Another long overdue change is to get rid of the old arcane & obtuse permissions model, replacing it with something which will be radically faster in installations with more than a few hundred users, as well as being more consistent, easier for people to control, and directly in alignment with the DAV ACL specification. Some of the work here was assisted by NZ Registry Services who gave me a Macbook to help with my compatibility testing. Not all of the changes are under the covers though. The new DAViCal also has a thoroughly revised administrative interface, and over the last couple of releases I've gone through the system trying to uncover all the places which were not properly localisable, too, so if you see DAViCal displaying strings in a language you didn't configure it for, it should be a fixable thing. I'd like to particularly thank Masahiro Mikami for turning around some Japanese translations very quickly which enabled me to quickly and visually see what was not properly translatable. There's still more work to do (there's always more work to do) but a fully translated DAViCal should, I hope, be quite usable by non-English speakers now. The new DAViCal also supports some rather significant extra functionality beyond the CalDAV standard, in particular we can thank Rob 'Cave' Ostensen for providing an implementation of pub/sub event change notifications. This version also supports draft 2 of the proposed WebDAV synchronisation standard - that's still under development, but we expect to track pretty close to released versions of that. Of course with all of this work there are some areas that didn't get changed. I didn't manage to finish an implementation of the scheduling extensions draft, much as I would have liked, but that is going to become very much a focus in the coming couple of months, and I'll be calling it "1.0" when things settle down after we get that done. Other things I will be working on include a ticketing system for providing targeted, controlled access to a specific collection or event, and making a start on CardDAV support for addressbook storage. DAViCal seems to be fitting a need for people, and I know there are several thousand installations around the world, even if I'm not sure where they all are. I know some people are running DAViCal on their 8-way server, where I've no doubt it gurgles along pretty happily, and that there are some people running it on their OpenWRT installation, with some tiny amount of resources - just enough for a family calendar. Traffic on the wiki has increased to several hundred thousand hits per month, perhaps three times what it was a year ago, and I hope that I can continue to provide a valuable and useful piece of infrastructure for that little calendaring corner of your organisation. What heartens me the most in this ongoing experience is the nascent community that appears to be forming around my software, with people writing 'tip sheets' and helping to answer questions on the IRC channel and mailing list. These small contributions made by many people - people whom I have never met, for the most part - are enabling me to put more time into feature development and expansion, and that's what I really love.

A friend e-mailed me this morning asking for some help with a problem he had where he wanted to make a folder writable by a group of people without making the files deletable. Stepping back from his question, I first pointed out that if the files are editable then they can be effectively deleted by removing the content from them, regardless of whether the directory entries themselves are retained. One solution which occurred to me would be to automatically version the content of the directory, and this reminds me of why versioning of /etc has never worked for me: it only happens when I remember to commit.
<!--break-->
Normally when I edit files in /etc, I am focused on achieving something now, and not on being able to undo it later. To this end I have written myself a script which will commit the contents of a directory (including adding new files and removing deleted ones) into a git repository, as follows:

#!/bin/sh
#
# Allow for debugging.
[ -n "$DEBUG" ] && set -o xtrace
cd $1
MESSAGE="Autocommit"
# Initialise the directory if it's not in Git currently
if [ ! -d .git ]; then
  git init
  MESSAGE="Initial commit"
fi
# Any files that aren't in the directory, but are in the repository can be removed.
for F in  git ls-tree HEAD   cut -f2 ; do
  [ -e "$ F " -o -L "$ F " ]   git rm "$ F "
done
# Any files that are in the directory, but aren't in the repository can be added
git add .
# And commit...
git commit -m "$MESSAGE"

So this script takes one parameter: the name of the directory where changes have (presumably) occurred, and just blindly commits everything there. The magic glue, then, is the awesomeness that is 'incron' :-) My first target is the ~/bin directory of all of those useful little scripts that I tend to randomly edit without nearly enough version control:

incrontab -e
home/andrew/bin IN_MODIFY,IN_DELETE,IN_CLOSE_WRITE,IN_MOVE \
     /home/andrew/bin/commit-directory /home/andrew/bin 2>&1   logger -t andrew-bin

With this, it means that whenever a file changes, is deleted from, moved into, or out of the directory we are monitoring, our commit-directory script is run. Just for testing I delete some ancient files that should have been killed a few computers back. A quick 'git status' in the directory shows everything was committed nicely. I edit a file and make some quick changes. Once again, I go into gitk and can see all the history. I sit back and ratchet my laziness another notch with a nice cup of tea, happy that, for now, at least, changes to my scripts are under revision control at last. Outstanding Issues Well, ok: it's usable as is, but there are a few small things that could be improved:

• When I edit a file, the temporary swap file gets committed, and then deleted as the changes get committed
• If I make a whole lot of changes the script can fire multiple times, or even fire before some changes fully happened
• Maybe I want a shadow folder maintained and committed, rather than just this folder
• Perhaps it would be a good idea to push the repository elsewhere

I'll keep monitoring in the real world if these are real annoyances, and whatever other annoyances I find, and maybe I'll tweak that commit script a bit more - add a delay and/or some locking too it. I don't think that adding some push would be too big a deal either, and I'd love to get suggestions from Git geeks as to how to do this more simply/reliably too.

I publish my photos on the internet. Well, I do when I get around to updating it, anyway. When I do so, I include some information about licensing them. I say to people "I'm very open to people wanting to use these pictures for something else, and will be happy to release photos into the public domain on request." so when I discover one of my photos abused by a travel website I do wonder why I didn't hear about it. Well it seems I also upload a lot of photos to the Burning Well public domain photo repository or to Wikimedia Commons where I also mostly mark them as PD-self. Still, you don't expect a photo of Cuilapan Monastery near Zaachila, Oaxtepec, Mexico to appear on a page about Edinburgh Castle, but really. Am I just being picky? Is this the norm? Are there really people all over the intawebs taking this little care about what photos they use for this sort of thing? I realise there isn't much sunshine in my photos of Scotland, and my photos of Edinburgh Castle, but really. Scotland is renowned for it's preponderance of rain over sunshine and it is considerably glossing the reality of a visit to the real Edinburgh Castle to even suggest the sun might appear. On closer examination I see that the site is actually talking about some weird nutter's home in Jamaica. Nothing to do with anywhere I've ever been, though if I ever visit Jamaica I probably would actually visit the place they're talking about. Now that I know about it, anyway, and especially if I was with Max who claims his favourite castles are Craigmillar & Tolquhon because most of the others aren't at quite the right stage of ruination. Oh well. I guess by putting the photo into the public domain I gave up responsibility for them, and it does seem that it might be hard to find real photos of the ruin in question (let alone free ones). On the other hand I do feel obliged to point and laugh, because that photo isn't Jamaica by a considerable distance, and just because I PD a photo I should still be well within my rights to have a good old giggle when I see a Mexican monastery linked to a Scottish castle. Even one in Jamaica.

I found another interesting avenue for affecting a web application recently when Heather was trying to renew one of her magazine subscriptions. She mentioned that the site was getting a '500 Server Error' and I recognised the e-mail address it was suggesting, so I banged an e-mail off to advise the problem. Curiously, they weren't able to duplicate the issue while I was still seeing the problem. I did a little fooling around and discovered that I only saw the error when I was making the request through my proxy server. A little more digging and I ascertained that if I connected to the proxy normally via IPv6 I got the '500 Server Error', but if I instead connected to the proxy via IPv4 it all worked just fine. Communicating this back to the site developer, it turns out the site had some blacklist checking in it which was checking not just my source IP (the site was only hosted on IPv4) but also checking the 'Via' header for my IP, which was coming through as an IPv6 address and causing the software to throw it's hands in the air at that point. So chalk up another interesting way in which an IPv6 address on the somewhat remote client can be passed through as input to a web application running on IPv4. I believe I've heard talk of ISPs considering running native IPv6 internally and proxying requests out to IPv4 in exactly this manner, so the sooner web developers realise that addresses could come in more than one shape, the better. And yet another reason to validate your data: just because you received a 'Via' header in the request does not mean there was ever a proxy involved in the request - it is untrusted data, people: like every other piece of data you receive down the wire from the client at the far end.

I released a new 0.9.7.2 version of DAViCal yesterday. This reflects quite a lot of stability and small fixes for some subtle problems, and quite a lot of work with the iPhone, adding the possibility of a simpler configuration experience for iPhone users. One long-standing, but less obvious problem (well, less obvious to me) was the handling of usernames with odd characters in them. In the round-trip these needed to be urlencoded, and that wasn't happening correctly in all places, but it hopefully is now. People who want to use e-mail addresses in usernames, or spaces in calendar names, or both, etc., should all work now. One newer problem I've been seeing the effects of a little recently is that PHP 5.3 deprecates call-time pass by reference, which I had used in a few places. That's fixed now, so it should be OK to upgrade to PHP 5.3 without breaking DAViCal or having to explicitly turn those warnings off. The iPhone is a curious beast. Lots of people love them, and it is about the only mobile device that supports CalDAV (though I'm hoping the Nokia N900 also will), so it's important to support it as transparently as possible regardless of my personal loathing for it's horribly locked down state. It was pointed out to me that it is possible for it to be configured by entering three pieces of data (domain name, username, password) so I decided to make DAViCal support that process. In order for it to work for you you will need to have DAViCal running on an SSL server on port 8443, which isn't too big a deal. You can also plain http on 8008 which it will also attempt after prompting when the SSL connection fails. You'll also have to enable mod_rewrite and use some rewriting rules like the example on the wiki. For myself, I use the free SSL certificates from CACert.Org so I had to browse to their root certificate page and load the class 1 and class 3 certs into the iPhone before it would talk happily to my DAViCal server. I'm hoping to continue with reasonably frequent incremental releases of DAViCal for the rest of the year, hopefully with 0.9.7.4 sometime in late October. What will be included there might also depend on how productive my visit to CalConnect XVI is in three weeks too, and I'm looking forward to that.